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(57) Abstract: The invention relates to a computer network for configuration, installation, monitoring, error-diagnosis and/or anal- 
ysis of several physical technical processes, in particular electrical drive processes, which occur under the control, regulation and/or 
monitoring of several process computer nodes, connected by means of at least one common communication system to at least one di- 
agnosis computer node, in which one or several configuration, monitoring and diagnosis services and/or functions are implemented, 
provided for the processes and/or the process computer nodes and/or the data processing processes running therein, whereby the 

Oconunon communication system is achieved by means of the Ethernet, or a similar asynchronous and/or bus or communication sys- 
^^^^ tem working with a stochastic access method. 

[Fortsetzung auf der ndchsten Seite] 
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VerofTentlicht: 

— ohne intemationalen Recherchenbericht und emeut zu ver- 
qffentlichen nach Erhalt des Berichts 



7Mr Erkldrung der Zweibuchstahen-Codes und der anderen Ah- 
kiirzungen wird auf die Erkldrungen ("Guidance Notes on Co- 
des and Abbreviations") am Anfang jeder reguldren Ausgabe der 
PCT-Gazette verwiesen. 



(57) Zusammenfassung: Rechner-Netzwerk zur Konfiguration, Inbetriebnahme, Obenvachung, Fehler-Diagnose und/oder -Ana- 
lyse mehrerer technisch-physikalischer Prozesse, insbesondere elektiischer Antriebsvorgange. die unter der Steuerung, Regelung 
und/oder Uberwachung durch mehrere Prozessrechnerknoten ablaufen. welche tiber wenigstens ein gemeinsames Kommunikations- 
system mit wenigstens einem Diagnoserechnerknoten verbunden sind, in dem ein oder mehrere Konfigurations-. tJberwachungs-, 
Diagnosedienste und/oder -funktionen implementiert sind, die den Prozessen und/oder den Prozessrechnerknoten und/oder den darin 
ablaufenden Datenverarbeitungsprozessen zugeordnet sind, wobei das gemeinsame Kommunikationssystem mit dem Ethernet oder 
einem sonstigen, asynchron und/oder mit einem stochastischen Zugriffsverfahren arbeitenden Bus- oder Kommunikationssystem 
realisiert ist. 
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Rochnernetzwerk mit Diagnoserechnerknoten 

Die Erfindung betrifft ein Rechnernetzwerk zur Konfiguration, Inbetriebnahme, 
Oberwachung, Fehler-Dlagnose und/oder -Analyse mehrerer technisch-physikalischer 
5 Prozesse. Solche kOnnen insbesondere elektrische Antriebsvorgange sein. die unter 
der Steuerung, Regelung und/oder Oben/vachung durch mehrere 
Prozessrechnerknoten (im Beispiel eines elektrischen Antriebssystems: Antriebsregler) 
ablaufen. Die Prozessrechnerknoten sind Qber wenigstens ein gemeinsames 
Kommunikatlonssystem mit wenigstens einem Diagnoserechnerknoten verbunden. In 
10 letzterenn sind ein Oder mehrere Konfiguratlons- Oberwachungs-, DIagnosedlenste 
Oder -funktfonen Implementiert, die den Prozessen und/oder den 
Prozessrechnerknoten und/oder den darin ablaufenden Datenverarbeitungsprozessen 
zugeordnet sind. 

15 Femer betrifft die Erfindung einen Diagnoserechnerknoten fur das genannte Netzwerk. 
Dieser ist als Server mit Schnittstellen fUr wenigstens eine Datenbank sowie zur 
Kommunikation mit wenigstens den Prozessrechnerknoten und mit sonstigen Client- 
Rechnerknoten ausgebildet. Welter betrifft die Erfindung einen 
Kcmmunikationsrechnerknoten Oder ein Kommunikattonsmodul, letzteres als Software- 

20 und/oder Firmwaremodul ausgebildet, welche jeweils zum Einsatz in das genannte 
Netzwerk geelgnet sind. 

Aus einem zusammenfassenden Tagurigsband zu dem im November 2001 in NOrnberg 
stattgefundenen KongrelJ „SPS IPC-Drlves" ist der Fachartikel „lnfo-Portal fOr 

25 anIagenQbergreifende Prozessvisualisierung und -management via Internet" (Autoren: 
Andreas Kitzler und Werner Felten) bekannt Darin wird eine Kommunikationsstruktur 
vorgeschlagen, bei welcher mehrere. voneinander unabhangige 
Automatlsierungssysteme, -zellen oder -aniagen uber ein Informationsportal 
kombinierbar, QbenA/achbar, visualisierbar und dergleichen sind. Auf das 

30 Informationsportal lasst sich Qber das Internet zugreifen. Die Kommunikation zwischen 
den Automatisierungszellen (sog. Supervisory Control And Data Acquisition - SCADA) 
einerseits und dem zentralen Webserver des Informationsportals andererseits erfolgt 
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Qber Standard-Schnittstellen auf der Basis der erweiterbaren Auszeichnungssprache 
XML Dazu ist jedes Automatisierungssystem miteinem sogenannten XML-Agenten zur 
Kommunikation mitdem Informationsportal auf der Basis von TCP-IP versehen. So soil 
ein Management Qber das Web verschiedene Automatisierungszellen bzw. SCADA- 
5 Systeme qualifiziert auswerten konnen. Allerdings mQssen die einzelnen Sensordaten. 
bevor sie vom Informationsportal Ober das Web transportiert werden konnen, zunachst 
auf der fOr sie spezifischen Ebene gesammelt, dort aufbereitet und dem 
Informationsportal Ober die XML-Agenten zur VerfQgung gestellt werden. 

10 Aus DE 196 14 748 (A1-Offenlegungssohrift und C2-Patentschrift) ist ein 
Fehlerdiagnosesystem bekannt, bei welciiem ein Diagnoserechnerknoten Ober 
mehrere Bussysteme auch auf der Basis des Kommunikationsprotokolls TCP/IP 
(Transport Control Protocol/Interface Program) mit Leitstandrecinner, 
Steuerprozessrechner und Feldprozessrechnern kommuniziert. Zur Kommunikation 

15 zwisclien deh Feldprozessreclinern einerseits und dem Diagnoserechnerknoten 
andererselts wird ein serieller Feldbus nach dem Standard RS485 eingesetzt. wobei 
der Diagnoserechnerknoten den seriellen Feldbus (RS485) entsprechend dem 
Master/Slave-Prinzip dominiert. Die Bandbreite fur die DatenObertragung (RS485 
Schnittstellen) reicht bei der zunehmenden . Datenflut nicht aus. Die auf der 

20 Bedienoberflache darzustellenden Infomiationen konnen aufgrund der Ring- 
Kommunikationsstruktur innerhalb eines Feldprozessrechner-Clusters nicht schnell 
genug Obertragen werden. Die Abfrage eines Parameters dauert etwa 50 -60 ms - bei 
Aniagen mit ca. 500 Antrieben wQrde z.B. ein anstehender Fehler erst nach mehr als 
einer Minute angezeigt werden. Jeder Parameter wird einzein Obertragen. die 

25 Obertragung von Software-Paketen ist nicht mSglich. 

Ziel der vorliegenden Erfinder ist es. ein Hard- und insbesondere Softwarewerkzeug 
zur Diagnose komplexer technischer Aniagen und Systeme zu entwickeln. das auf die 
Anforderungen und BedOrfnisse der Benutzer zugeschnitten ist und vor allem 
30 folgenden Anforderungen genOgt: 



(1) Flexible Funktionen zur Oberwachung und Diagnose groBer Antriebssysteme: 
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Ziel der Erfindung ist die Ent>Ancklung eines Hard- und insbesondere 
Softwarewerkzeugs zur Uberwachung und Diagnose von insbesondere groGen 
Antriebssystemen. Das Diagnosesystem soli umfangreiche, flexible Funktionen bieten, 
die auf die zT. sehr unterschiedlichen Bedtirfnisse der verschiedenen 
Benutzergruppen beim Kunden zugeschnitten sind. 

(2) Einfach zu bedienende. ubersichtllche Bedienoberfl^chen: 

Die Bedienoberflache des Diagnosesystems ist der einzige Teil der Software, mit der 
der Kunde in Kontakt kommt Insofern ist sie das „Aushangeschild" der Software und 
fur deren Akzeptanz und Beurteilung von Selten des Kunden entscheidend. Beim 
Entwurf der Bedienoberflache ist darauf zu achten, dass sie aucli fur wenig geschultes 
Personal leicht zu bedienen ist. Die Vielzahl der bei der Diagnose von groRen Aniagen 
anzuzeigenden Informationen mulS graphisch aufbereitet werden und in einer 
ergonomischen Darstellung dem Anwender pr^sentiert werden. 

(3) VerkOrzung der zur Auffindung eines eventuellen Fehlers notwendigen Zeit: 

Der Nutzen des Diagnosesystems soil fur den Kunden darin liegen, dass er sofort nach 
dem Auftreten eines Fehlers im Antriebsystem die fur die Auffindung und Behebung 
des Fehlers notwendigen Informationen prasentiert bekommt. Hierdurch kann die Zeit 
in der die Aniage nicht produktiv ist. reduziert werden. 

(4) Situationsabhangige Darstellung von Diagnose-lnformationen 

Das Diagnosesystem soil die richtige Infomnation zum richtigen Zeitpunkt am richtigen 
Ort zur Verfugung stellen: 

• Aufbereitung der Diagnose-lnformation gemalS den Anforderungen des 
jeweiligen Benutzerkrelses (z.B. Aniagenbediener, Techniker, 
Inbetriebnehmer) {-> die richtige Information) 

• Zeitnahe Anzeige von Diagnose-lnformationen direkt nach Auftreten eines 
Fehlers zum richtigen Zeitpunkt) 

• Zugriff auf DAS DIAGNOSESYSTEM von beliebigen PCs des Kunden ohne 
Installationsaufwand - sowohl im lokalen Kundennetz als auch Qber 
Fernzugriff. (-» am richtigen Ort) 



wo 2004/014022 




PCT/EP2003/050349 



(5) Reduzierung von kritischen Anlagenzustanden durch vorbeugende Wartung und 
standige Oberwachung der Aniage: 

ZukOnftig soli das Diagnosesystem Mechanismen beinhatten, die dazu beitragen, 
eventuell bevorstehende Ausfalle yon Geraten vorab zu erkennen und dem Kunden 
mitzuteilen. So kann die Zuverlassigkeit des Antriebsystems weiter erhoht werden. 

(6) Umfassende Diagnose- / Messfunktionen via schneller Ethernet-Schnittstelle unter 
Einbeziehung ^ des Ethernet-Gesamtkonzeptes der Maschine um z.B. ein 
Referenzsignal einer realen Leitachse zu messen, aufzuzeichnen und auszuwerten 

(7) Vorbeugende Diagnose (z.B. Geberausfall in ... Tagen wahrscheinlich) 

(8) Ein „Expertensystem" soil Fehleriokalisierung innerhaib max. 10 min sicherstellen 
und Fehlerbehebung wesentlich vereinfachen 

(9) Webbrowser-Funktionen 

(10) Das Diagnosesystem muss auf mehreren Plattfomnen laufen konnen (z.B. diverse 
Leitstande) 

(11) Integrierte Datenprotokollierung / -analyse (RegistenA/erte. Kommandos) muss 
ohne zusatziiche Hardware (Datenanalyzer) verfQgbar sein 

(12) Zyklische Datenprotokollierung auf zentralen Datenbankserver 

(13) Zugriffsmdglichkeit fur den Maschinenhersteller auf ausgelleferte Antriebssysteme 
per Ferndlagnose 

(14) BedlenerfUhrung und Parameterhandling (Konflguration, Inbetriebnahme, 
Fehlersuche, Software-Updates) sind wesentlich zu verbessern 
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(15) Entwicklung von branchenubergreifenden Losungen 

Trotz BerOcksichtigung der Kunden\A/Gnsche soli das Diagnosesystem fur den 
branchenQbergreifenden Einsatz entwickelt warden, so dass ein Einsatz in anderen 
Branchen (z.B. Werkzeugmaschinen, Textilmaschinen) ohne groRen Aufwand m6glich 
ist. 

(16) Bereitstellung der Softwarewerkzeuge fQr die inbetriebnahme von 
Antriebssystemen mit zukunftig bis zu 500 Achsen 

Antriebssysteme mit mehr als 300 Achsen sind oiine Softwareunterstutzung nur noch 
mit unverhaltnismaGig hohem Aufwand in Betrieb zu nehmen. Hierfur soil mit dem 
Diagnosesystem ein geeignetes Softwarewerkzeug entwickelt warden. 

(17) VerkQrzung der Inbetriebnahmezeit und Reduzierung der Inbetriebnahmekosten: 
Mit Hilfe des Diagnosesy stems sollen die Kosten fur die Inbetriebnahme durch/die 
Bereitstellung geeigneter softwaregestQtzter Verfahren langfristig reduziertwerden. 

(18) Weltweiter Zugriff auf den oder die technisch-physikalischen Prozesse der Aniage, 
insbesondere Antriebssystem. zur schnellen und kostengDnstigen Diagnose: 

FQr einen schnellen und zuverlSissigen Service und zur Aniagendiagnose soil ein 
weltweiter Zugriff auf das Antriebssystem moglich sein, 

Dem gegenOber wird zur Vermeldung sich aus dem Stand der Technik ergebender 
Nachteile bei dem Rechner-Netzwerk mit den eingangs genannten Merkmalen 
erfindungsgemSB vorgeschlagen. dass das gemeinsame Kommunikationssystem 
zwischen dem Prozessrechnerknoten und dem Diagnoserechnerknoten mit dem 
Ethernet oder einem sonstigen, asynchron und/oder mit einem stochastischen 
Zugriffsverfehren arbeitenden Bus- oder Kommunikationssystem realisiert wird. Ein 
derartiges Zugriffsverfahren ist beispielsweise unter der AbkQrzung „CSMA/CD" 
(Carrier Sense Multiple Access/with Collision Detection) bekannt. Dieser industrielle 
Ethernet-Einsatz zur Realisierung einer Kommunikations-lnfrastruktur ermoglicht im 
Vergleich zur vorbekannten Kommunikation uber RS485 und dem zugehorigen USS- 
Protokoll eine hohere Bandbreite fQr die DatenQbertragung, so dass grOliere 
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Datenmengen von dem ProzeBrechnerknoten zum Diagnoserechnerknoten ubermittelt 
werden konnen. HiorfOr besteht aufgrund der zunehmenden Komplexitat der 
technischen Aniagen mit wachsender Anzahl von Prozessrechnerknoten und 
zugehorigen technisch-physikalischen Prozessen ein zunehmendes BedCirfnis. 

5 Weiterhin hat sich das Ethernet im BQrobereich als weitgehender Standard far die 
Obertragung grower Datenmengen durchgesetzt. Durch die erfindungsgemaUe 
VenA/endung von Ethernet mit dem ebenfalls an sich bekannten Protokoll TCP/IP ist fOr 
das erfindungsgemalSe Diagnosesystem der Weg zur Kompatibilitat und/oder 
Verbindung mit dem Internet geebnet. Damit wird der Vorteil erzielt, dass 

10 Diagnosedaten uber das Internet verschickt werden kOnnen. Zudem kann eine 
technische Aniage mit einer Vielzahl von Prozessen von einem beliebigen Client- 
Knoten aus insbesondere uber das Internet uberwacht werden. 

Um die umfangreich anfallenden Datenmengen sinnvoll verarbeiten zu konnen, ist eine 
15 dezentrale Diagnose nebst Vorverarbeitung zweckmafiig. Ebenfalls sinnvoll ist es, 
umfangreiche Diagnosefunktionen mdglichst nahe an den betroffenen. technisch- 
physikalischen Prozess Oder Gerat anzusiedeln. In dieser Hinsicht ist nach einer 
vorteilhaften Erfindungsausbildung dem Ethernet oder dem sonstigen Bus- oder 
Kommunikationssystem und wenigstens einem der Prozessrechnerknoten ein 
20 Kommunikationsmodul oder -rechnerknoten zwischengeschaltet, das bzw. der den 
jeweiligen Prozessrechnerknoten an das Internet oder sonstige Bus- oder 
Kommunikationssystem anbindet. Der Kommunikationsrechnerknoten oder das 
Kommunikationsmodul kann zusatzlich auch noch die ereignls- und/oder 
anfragebasierte Kommunlkation zum Diagnoserechnerknoten Qbernehmen. 

25 

Insbesondere wenn in weiterer Ausgestaltung der Erfindung das Kommunikationsmodul 
Oder der Kommunikationsrechnerknoten so ausgebildet ist, dass es bzw. er Qber XML- 
Protokolle und/oder als XML-basierte Schnittstelle mit dem Diagnoserechnerknoten 
kommuniziert (XML: Extensible Markup Language), kann bei der Projektierung und 
30 Konfiguration der damit zu uberwachenden. technischen Aniage sehr flexibel und mit 
verhaitnlsmaiiig geringem Aufwand auf technische Anforderungen und 
KundenwQnsche reagiert werden. Auf der Basis der Erfindung I^St sich eine 
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standardisierte, flexible Netzwerk-Rechnerstruktur schaffen. die leicht urn weitere 
Funktionen erweitert werden kann. Vor allem lassen sich mit dem Einsatz der XML- 
Protokolle und/oder der XML-basierten Schnittstellen die Diagnosedaten aus dem 
Prozessrechner- und/oder Kommunikationsknoten fur den Diagnoserechnerknoten 
bereits so aufbereiten, dass diese vonn Diagnoserechnerknoten leicht uber das Internet 
an Client-Rechnerknoten ubertragen werden konnen. 

Urn die umfangreichen Datennnengen uber eine dezentrale Vorverarbeitung sinnvoll 
bewaitigen zu konnen, ist nach einer Ausbildung der Erfindung vorgesehen, dass das 
Kommunikationsmodul oderder Kommunikationsrechnerknoten mit Funktionalitaten zur 
Fehlersuche Oder Diagnose im Bereich wenigstens eines der Prozessrechnerknoten 
Oder eines technisch-physikalischen Prozesses versehen ist. Mit diesem Konzept 
lassen sich umfahgreiche Diagnosefunktionen nahe an den betroffenen Komponenten 
ansiedeln. 

Der Internet-Kompatibilitat des erfindungsgemaSen Diagnosesystems dient es, wenn 
nach einer Erfindungsausbildung der Diagnoserechnerknoten zur Bereitstellung oder 
wenigstens Unterstutzung webbasierter Bedienoberflachen fur Client-Rechnerknoten 
ausgebildet ist. Dies kann Qber Datenfernubertragung und/oder ein Weitverkehrsnetz 
(z. B. Internet) erfolgen. Ferner liegt es im Rahmen der Erfindung, wenn dazu der 
Diagnoserechnerknoten mit Funktionskomponenten versehen ist, welche die Bildung 
der Bedienoberflachen in den Client-Rechnerknoten unterstQtzen. 

Problematisch ist, ob der Benutzer an einem Client-Rechnerknoten sich sicher sein 
darf. dass die Client-BenutzeroberflSche (Diagnose-) Daten und -Informationen 
wiedergibt, die noch weltgehend aktuell bzw. zeitnah sind. Ein etwaiger Ausfall des 
Diagnoseservers soil erkennbar sein. und ferner sollen Fehler und sonstige Ereignisse 
im technisch-physikalischen Prozess und/oder Prozessrechnerknoten zeitnah dem 
Benutzer Qber die Bedienoberflache des ihm zugeordneten Client-Rechnerknotens 
mitgeteilt werden konnen. 
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8 



Zur LOsung dieser Problematik wird im Rahmen der allgemeinen erfinderischen Idee 
ein zum Einsatz als Server in das soeben skizzierte Netzwerk ausgebildeter 
Diagnoserechnerknoten mit folgenden Merkmalen vorgeschlagen: 

■ der Diagnoserechnerknoten ist zur Arbeit als Server eingerichtet und besitzt 
Schnittstellen zu wenigstens einer Datenbank, zur Kommunikation mit den 
Kommunikations- und/oder Prozessrechnerknoten und zur Kommunikation mit 
sonstigen Client-Rechnerknoten; 

■ die eine oder mehreren Schnittstellen zu den sonstigen Client-Rechnerknoten 
sind unter Verwendung eines (an sich bekannten) Servlet-Containers 
realisiert, welcher der Ubertragung von Diagnosedaten an die Clientknoten 
dient; 

■ diese Diagnosedaten sind aus den Schnittstellen erhaltlich. die der 
Kommunikation mit dem Kommunikations- und/oder Prozessrechnerknoten 
dienen; 

■ die eine oder mehreren genannten Schnittstellen, welche den 
Kommunikations- und/oder Prozessrechnerknoten zugeordnet sind, sind auf 
der Basis des Ethernet realisiert; 



■ es ist ein Diagnosekanal gebildet, der eine oder mehrere Ethernet- 
Schnittstellen umfasst, die den Kommunikations- und/oder 



■ der Diagnosekanal umfasst ferner ein Ereignis-Managementmodul, das auf 
die Datenbank zugreifen sowie an den Ethemet-Schnittstellen erhaltene 
Diagnosedaten verarbeiten kann; 



■ ferner umfasst der Diagnosekanal ein Ereignis-Oberwachungsmodul. das auf 
der Basis des Servlet-Containers gebildet ist und Ausgangsdaten aus dem 



25 



Prozessrechnerknoten zugeordnet sind; 



30 
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Ereignis-Managementmodul einem oder mehreren Applets auf externen 
Client-Rechnerknoten zur VerfOgung stellt. 

Damit ist es mOgllch, Daten, insbesondere Diagnosedaten, zwischen dem 
5 Diagnoserechnerknoten und der Benutzeroberflache eines Client-Rechnerknotens 
zyklisch Qbertragen zu konnen. So kann ein Benutzer am Client-Rechnerknoten 
zeitnah uber im Bereich der Prozessrechnerknoten und/oder der technisch- 
physikalischen Prozesse auftretende Ereignisse informiert werden. Dem Benutzer 
kOnnen in vielfaltiger und komfortabler Weise so Anlageinformationen auf der 
10 Benutzeroberflache des Client-Rechnerknotens zur VerfQgung gestellt werden. Die 
Datenubertragung lasst sich besonders vorteilhaft mit Java-Technologien realisieren, 
namlich einem Java-Servlet auf dem Diagnoserechnerknoten als Server und einem 
Java-Applet beim Client-Rechnerknoten. So ist es auch moglich, einen Benutzer am 
Client-Rechnerknoten Diagnoseinformationen in Form von Webseiten zur Verfugung 
15 zu stellen. Dabei bietet der Einsatz von Java-Applets sehr flexible 
Darstellungsmoglichkelten, die durch den Zukauf von Applets mit grafischen 
Fahigkeiten leicht erweiterbar sind. 

Der LOsung der obigen Problematik dient der erfindungsgemaSe Diagnosekanal im 
20 Diagnoseserver, mittels welchem eine zyklische Kommunlkation realisiert werden kann, 
wobel regelmaBig Datenpakete ausgetauscht werden. Fehit ein Datenpaket, kann im 
Client-Rechnerknoten erkannt werden, dass ein Fehlerfall aufgetreten ist („Event + 
Heartbeat"). Der Heartbeat bzw. Herzschlag entspricht gleichsam der vor allem in der 
Eisenbahn-Sicherheitstechnik bekannten Totmannstaste. Mittels des Diagnosekanals 
25 lasst sich also eine Anzeige von vom Prozessrechnerknoten herruhrenden 
Diagnosedaten Qber den Diagnoseserver bzw. Diagnoserechnerknoten zum Client- 
Rechnerknoten auf dessen Bedienoberflache gleichsam triggern. Die Darstellung des 
Fehlerfalls auf der Benutzeroberflache ist aufgrund des erfindungsgemalien 
Diagnosekanals nicht mehr davon abhangig, dass vom Client-Rechnerknoten eine 
30 Anfrage zum Diagnoseserver Qbermittelt wird. Vielmehr konnen die 
Prozessrechnerknoten. gegebenenfalls uber jeweils eigens zugeordnete 
Kommunikationsknoten. gleichsam selbst die Darstellung neuer Ereignisse, 
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insbesondere Fehler, indizieren. Dieser Mechanismus wird wesentlich durch den 
Diagnosekanal Im Diagnoserechnerknoten unterstutzt, indem uber das Ereignis- 
Oberwachungsmodul vom Prozessrechnerknoten mitgeteilte Diagnose- bzw. 
Fehlerdaten an die Bedienoberflache des Client-Rechnerknotens fur einen dortigen 
5 Benutzer weitergeleitet warden. 

GemaU einer besonderen Ausbildung sind die Schnittstellen im 
Diagnoserechnerknoten fur Kommunikation mit den Kommunikations- und/oder 
Prozessrechnerknoten mittels XML-Protokolle bewerkstelligt. Dadurch lassen sich in 
10 der Flexibilltat eingeschrankte. proprietare Losungen vermeiden. 

Im Diagnoserechnerknoten sollen alle Diagnoseinformationen den 
Benutzeroberflachen auf den Client-Rechnerknoten webbasiert zur Verfugung gestellt 
warden. Als besonders zweckmafiig dafur stellte sich eine Kombination des 
15 Webservers Appache mit der Servlet-Engine „Tomcar heraus. 

Bei dem oben angegebenen, erfindungsgemaBen Diagnoserechnerknoten sorgt der 
Diagnosekanal dafOr, im Ereignis-, insbesondere Fehlerfall den Client-Rechnerknoten 
darauf mit seiner Benutzeroberflache zur Reaktion zu bringen. Tritt ein Fehler oder ein 

20 Ereignis auf. werden entsprechende Diagnosedaten an der Ethernet-Schnittstelle des 
Diagnosekanals erfasst, welche den Kommunikationsmodulen, Kommunikations- 
und/oder Prozessrechnerknoten zugeordnet sind. Auf die Diagnose- bzw. 
Ereignisdaten in Form beispielsweise eines Telegramms an der Ethernet-Schnittstelle 
kann das Erelgnis-Managementmodul zugreifen. Die Ereignis- bzw. Diagnosedaten 

25 werden verarbeitet und eine entsprechende Information in die Datenbank geschrleben. 
Die Ausgangsdaten aus dem Ereignis-Managementmodul gelangen zu dem im Servlet- 
Container angelegten Ereignis-OberwachungsmoduL Dieser Qbermittelt an seinem 
Ausgang eine Information im Beispielsfall des Intranets zweckmaSig direkt. ohne 
Zwischenschaltung eines Webservers, an einen Client-Rechnerknoten, Die Information 

30 beinhaltet eine Aufforderung, beim Diagnoseserver wegen Ereignisse oder Fehler 
reprasentierende Diagnosedaten nachzufragen. Damit wird die Notwendigkeit eines 
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standigen, den gesamten Betrieb uber andauernden Pollings, was erhOhte 
Datenubertragungskapazitaten erfordern wOrde, vermieden. 

Zur Anbindung der Prozessrechnerknoten an das Ethernet oder ein sonstiges, 
asynchron arbeitendes Kommunikationssystem mit dem Diagnoserechnerknoten, und 
insbesondere zur Schaffung der Moglichkeit einer ereignisbasierten Kommunikation 
zwischen Prozessrechnerknoten und Diagnoserechnerknoten, wobei umfangreiche 
Diagnosefunktionen m6glichst nahe zum technisch-physikalischen Prozess verlagert 
werden, wird im Rahmen der allgemeinen erfinderischen Idee ein 
Kommunikationsrechnerknoten Oder ein Kommunikationsmodul als Software- und/oder 
Firmwaremodul vorgeschlagen, der zur Verwendung im oben skizzierten Rechner- 
Netzwerk geeignet ist und sich durch folgende Merkmale auszeichnet: 

■ der Kommunikationsrechnerknoten oder das Kommunikationsmodul weisen 
eine erste Schnittstelle auf, die dem wenigstens einen 
Diagnoserechnerknoten zugeordnet ist; 

■ diese Schnittstelle ist zur Kommunikation uber Protokolle der TCP/IP-Familie, 
einschllelilich UDP/IP, vorzugsweise auf der Basis des Ethernet programmiert 
oder ausgebildet; 

■ der Kommunikationsrechnerknoten bzw. das Kommunikationsmodul weisen 
eine oder mehrere zweite Schnittstellen auf, die einem oder mehreren der 
Prozessrechnerknoten zugeordnet slnd, 

■ die erste und die eine oder mehreren zweiten Schnittstellen sind miteinander 
Qber einen oder mehrere Informationsbroker koppelbar; 

■ der eine oder die mehreren Informationsbroker sind jeweils programm- 
und/oder schaltungstechnisch als Submodule fQr bidirektionale, anfrage- 
und/oder ereignisbasierte Datenkommunikation eingerichtet, die zwischen der 
ereten und der einen oder den mehreren zweiten Schnittstellen stattfindet. 
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Zweck des Kommunikationsmoduls bzw. Kommunikationsrechnerknotens ist es, 
samtliche Kommunikationsaufgaben zwischen dem Prozessrechnerknoten und dessen 
AuRenwelt abzuwickeln. Hierzu gehort z. B. der Zugriff auf Parameter des 
Prozessrechnerknotens, beispielsweise Antriebsreglers, der Down- und Upload von 
beispielsweise Regler-Firmware und zugehoriger Datensatze. sowie die Bereitstellung 
von Diagnosefunktionalitaten. 

Im Hinblick auf die Realisierung der Hardware des erfindungsgema&en 
Kommunikationsknotens konnte es zweckmaRig sein, eine eigenstandige Baueinheit 
mit darin integrierten Kommunikationsfunktionen zu fertigen und auf die Platine fur den 
Prozessrechnerknoten aufzustecken. Alternativ kann die Kommunikationsknoten- 
Hardware ganz oder teilweise in die Schaltung auf der Platine des 
Prozessrechnerknotens und/oder der des Diagnoserechnerknotens integriert sein. 
Alternativ liegt es auch inn Rahmen der Erfindung, den Konnmunikationsknoten 
gleichsam als „PC" mit einem eigenen Gehause auszufuhren, das auf eine 
Schienenhalterung fur den Prozessrechnerknoten mit aufgeschnappt werden kann. 

Als Betrlebssystem far den erfindungsgennaBen Kommunikationsknoten 
(Kommunikationsmodul oder Kommunikationsrechnerknoten) hat sich der Einsatz von 
Linux als zweckmaiilg erwiesen, was Lizenzkosten fur die Entwicklungsumgebung 
entfellen ISsst. Zudem ist C"*^ als ausreichend flexible und machtige 
Programmiersprache geeignet. 

Mit der erfindungsgemaBen Konzeption des Kommunikationsknotens zwischen 
Prozessrechner und DIagnoserechner ergibt sich die Moglichkeit for die Obertragung 
der Daten an die AuBenwelt uber XML-basierte Protokolle (anstelle von proprietSren 
Protokollen). IVlit der an sich bekannten und weit verbreiteten Auszeichnungssprache 
XIVIL fQr Internetanwendungen in Verbindung mit der Bereitstellung 
plattformunabhangiger XML-Parser ergibt sich ferner die MSglichkeit, auch in 
heterogenen Systemumgebungen einfach Daten auszutauschen. Durch bereits 
vorhandene Validierungsmechanismen (XML-Schema) kOnnen die Struktur und der 
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13 



zulassige Inhalt eines Telegramms einfach festgelegt werden, wobei die PrQfung auf 
Gultigkeit automatlsch erfolgt. Als zeichenorientiertes Protokoll ist ein XML-basiertes 
Telegramm einfach zu erzeugen und notfalls auch von Hand Oder von einfachen 
Skripten zu bearbeiten. 

5 

Um mOglichst umfangreiche Diagnosefunktionen moglichst nahe am technisch- 
physikalischen Prozess implementieren zu kOnnen, wird gemaiJ einer vorteilhaften 
Erfindungsausbildung vorgeschlagen, dass der eine oder die mehreren 
Informationsbroker Funktionskomponenten umfassen, die zur Fehlersuche oder 

10 Diagnose im Berelch der Prozessrechnerknoten und/oder technisch-physlkalischen 
Prozesse ausgebildet sind. Vor allem in diesem Zusammenhang ist die weitere 
Erfindungsausbildung vorteilhaft, auf dem Kommunikationsreciinerknoten oder -modul 
einen Interpreter fur die Ablauffahigkeit von an sich bekannten Skripten einzurichten, 
die zum Zugriff auf Funktionselemente beziehungswelse Funktionalitaten in dem oder 

15 den Informationsbrokern zwecks Ausfuhrung von ObenA/achungs- und 
Diagnosefunktionen ausgebildet sind. Ein damit erzielbarer Vorteil besteht in der 
effektiveren Fehlersuche: Mittels der Skripten in Verbindung mit der Sprache Perl 
lassen sich in relativ einfacher Weise effiziente Fehlersuchbedingungen einrichten 
bzw. vom Diagnoserechnerknoten auf dem Kommunlkationsknoten laden. Damit lasst 

20 sich die Funktionalitat. die auf dem Kommunlkationsknoten zur VerfQgung steht. noch 
einmal erweitern. 

Es liegt im Rahmen der Erfindung, dass das Kommunikationsmodul Oder der 
Kommunikationsrechnerknoten in bestlmmten Fallen dann als Server gegenOber dem 
25 Diagnoserechnerknoten (als Client) arbeitet, wenn seitens des 
Diagnoserechnerknotens Anforderungen an Informationsdienste vorliegen, die 
beispielsweise von Informationsbrokern im Kommunlkationsknoten auszufOhren sind. 

Weitere Einzelheiten, Merkmale, Vorteile und Wirkungen auf der Basis der Erfindung 
30 ergeben sich aus der nachfolgenden Beschreibung bevorzugter beispielhafter 
AusfOhrungsformen der Erfindung und aus den Zeichnungen. Diese zeigen in: 
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Figur 1 ein schematisches Gerateschaubild des 
erfindungsgemarjen Diagnosesystems mit lokalem und weltweitem 
Zugriff auf Diagnoseinformationen; 

Figur 2 eine schematische Block-Darstellung eines 
beispielhaften Kommunikationssystems eines mit dem 
erfindungsgem^fSen Diagnosesystem versehenen, elektrischen 
Antriebssystems; 

Figur 3 in schematischer Blockdarstellung die Grobstruktur 
des erfindungsgemaBen Diagnosesystems; 

Figur 4 eine detaillierte Blockbild-Darstellung der internen 
Struktur des Diagnose-Rechnerknotens; 

Figur 5 eine gleichartige Blockdarstellung der internen 
Struktur des Kommunikations-Rechnerknotens; 



Figure eine beispielhafte Bedienoberflache auf einem Client- 
20 Rechnerknoten fOr ein anlagenorientiertes Aniagenbild am Beispiel 

einer Druckmaschine. erzeugt mittels eines Java-Applets in 
Verbindung mit einem korrespondierenden Servlet auf dem 
Diagnoserechnerknoten; 

25 Figur? eine weitere. gleichartig erzeugte Bedienoberflache 

uber ein antriebssystem-orientiertes Aniagenbild am Beispiel einer 
Druckmaschine. 



GemaB Figur 1 ist ein elektrisches Antriebssystem fOr eine Vielzahl von zueinander 
30 synchron anzutreibenden Achsen 1 belspielsweise einer Druckmaschine mit einer 
Vielzahl von Elektromotoren 2 versehen, die jeweils eine Achse 1 antrelben. Die 
Elektromotoren 2 werden Jewells Qber Wechselrichter 3 mit vorgeschalteten 
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Prozessrechnerknoten 4, im vorliegenden Druckmaschinen-Antriebssystem als 
Antriebsregler ausgefQhrt, angesteuert bzw. geregelt. Zur Kommunikation mit einem 
Diagnoserechner-Knoten sind den Prozessrechnerknoten jeweilige 
Kommunikationsrechnerknoten 5 vorgeschaltet. Der Wechselrichter 3, der 
5 Prozessrechnerknoten 4 und der Kommunikationsrechnerknoten 5 konnen baulich auf 
einer gemeinsamen Baugruppe, wie zeichnerisch dargestellt, integriert sein. welche in 
einem jeweiligen Schaltschrank 6 untergebracht ist. 

GemaR Figur 1 kann der Diagnoserechnerknoten auch mit einem Leitstand, mehreren 
10 Client-Rechnerknot^n fur Diagnose und uber einen Internet-Router oder ISDN oder 
analog Qber das Internet mit einem oder mehreren, ortlich entfemten Client- 
Rechnerknoten zur Ferndiagnose kommunizieren. Damit sind die am jeweiligen 
Antriebsprozess der Elektromotoren 2 mittels des Prozessrechnerknotens 4 und/oder 
des Kommunikationas-Rechnerknotens 5 aufbereiteten Diagnosedaten uber den 
15 Diagnoserechnerknoten sowohl lokal als auch von einem beliebigen Ort aus abrufbar. 

GemaS Figur 2 sind die einzelnen Prozessrechnerknoten 4 im Rahmen einer 
Ringstruktur zur synchronisierten Kommunikation miteinander verbunden, wobei stets 
einer der Prozessrechnerknoten 4 (in Figur 2 der jeweils dunkler unterlegte) als 
20 Kommunikationsmaster arbeitet. Dieser besitzt gleichzeitig eine Schnittstelle zur 
asynchronen Kommunikation Qber das Ethernet mit mehreren 
Steuerungsrechnerknoten SPS. Urn auch eine Querkommunikation zwischen einzelnen 
Ringen mit Prozessrechnerknoten 4 zu unterstQtzen, ist als Strukturelement noch ein 
Multi-Link-Controller MLC eingefOhrt (an sich bekannt aus US 2003/0100961 A1). 

25 

In der Leitebene werden standig (Diagnose-) Informationen aus der Ebene der 
Prozessrechnerknoten 4 benOtigt. Dabei handelt es sich im wesentlichen um 
Systeminformationen wie Status- und Fehlermeldungen, Wartungsinformationen sowie 
Aufeeichnungen zur Qualitatsuberwachung. Zur Auswertung der Daten steht in der 
30 Leitebene der in Figur 2 gezeichnete Diagnose-Rechnerknoten zur Verfugung. Auch 
hier wird das an sich bekannte Ethernet als Kommunikationsmedium sowohl zu den 
einzelnen Prozessrechnerknoten 4 als auch zu den Diagnosestationen in der 
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Leitebene zur Verfugung gestellt, welche Client-Rechnerknoten mit 
Benutzeroberflachen bilden konnen. Das an sich bekannte OSI-Schichtenmodell 
ermOglicht komplexe Kommunikationsmechanismen zwischen Prozessrechner- und 
Leitebene. Da die Diagnose unabhangig von der restlichen Kommunikation erfolgen 
soli, ist jeder Prozessrechnerknoten 4 Qber das Ethernet vom Diagnoserechnerknoten 
(und umgekelirt) erreichbar Damit wird u. a. der Vorteil erzielt, dass auch 
Kommunikationsprobleme im synchronisierten Ringbus der Prozessrechnerknoten 
untereinander erkannt werden konnen. 

Definition wichtiger Begriffe: 

Ereignis Ein Ereignis ist eine Information die von einem 

Antriebsregler (Prozessrechnerknoten am technisch- 
physikalischen Prozess) beim Auftreten an den Diagnose- 
Server (Diagnoserechnerknoten) gesendet wird. Es 
erscheint in der Ereignisanzeige der Bedienoberflache und 
im Logbuch. Ereignisse sind z.B. Fehlermeldungen, 
Meldungen Qber den Start/ Stop von Aufeeichnungen, 
Wartungsmeldungen etc. Jedes Ereignis hat eine 
eindeutige Ereigniskennung uber die eine 
Ereignisbeschreibung in der Dokumentation abgerufen 
werden kann. 

Aufzeichnung Mit einer Aufzelchnung kann man beliebige 

Parameterverlaufe von beliebigen Reglern erfassen und In 
einer Datenbank speichern. 

Oberwachungsansicht Die Oberwachungsansicht ist eine graphigche Darstellung 

eines Oder mehrerer Parameter von einem Oder mehrerer 
Regler. Sie dient dazu, den Werteverlauf dieser Parameter 
hinsichtllch Abweichungen von der Norm zu Oberwachen. 
(z.B. Oberwachung der Motortemperatur) 
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Parameterliste Die Parameterliste enthalt alle an einem Reglertyp 

vorhandenen Parameter 



Langzeitaufzeichnung 



Eine Aufzeichnung, deren Daten auf dem Diagnoseserver in 
einer Datenbank gespeichert werden. Gegenteil zur 
Ringspeicheraufzeichnung 



Ringspeicheraufeeich- 
nung 



Eine Aufzeichnung. deren Daten in einenn Ringspeicher des 
Prozessrechnerknotens gespeichert werden. Erst nach 
Beenden der Aufzeichnung konnen die Daten auf dem 
Diagnose-Server gespeichert werden. 



Konfigurations-Wizard Eine Abfolge von einzelnen Seiten auf denen der Benutzer 

Einstellungen vornehmen kann. Jeder Schritt in der 
Konfiguration umfasst eine Anzahl von Funktionen und wird 
auf einer Seite dargestellt. Je nachdem wie der Benutzer 
sich im vorherigen Schritt verh^lt, wird eine entsprechende 
Nachfolgeseite angezeigt. (z.B. bei Konfiguration der 
Aufzeichnung: Auswahlmoglichkeit im Schritt 1: 
Ringspeicher oder Langzeitaufeeichnung: Je nach Auswahl 
bekommt der Anwender Seiten fur die Konfiguration des 
Ringspeichers oder der Langzeitaufzeichnung angezeigt.) 



Figur 3 gibt einen Gberblick Qber die Grobstruktur des Diagnosesystems. Dem 
5 Anwender stehen verschiedene web-basierte Bedienoberfiachen zur Verfugung, die 
ihm die Funktionalitat des Diagnosesystem in einer fQr ihn geeigneten Darstellung 
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prasentieren. Fur die Bedienung des Systems ist es unerheblich, ob sich der Benutzer 
lokal an der Aniage Oder an einem anderen Ort befindet. 

Die vom Benutzer gewunschten Funktionen warden von den,Benutzeroberflachen an 
den Diagnose-Rechnerknoten weitergeleitet. Hier ist jede Funktionalitat, die in der 

5 Oberfiache zur Verfugung steht, implementiert. Weiter Qbernimmt der Diagnose- 
Rechnerknoten die Speicherung von alien anfallenden Daten in der Datenbank DB. 
Alie aniagenspezlfischen Daten wie z.B. die Anlagenkonfiguration oder 
Bauteildatenbanken, alie diagnosespezifischen Daten wie z.B. Langzeitaufzeichnungen 
Oder Ringspeiclnerdaten sowie anwendungsbezogene Daten werden in der Datenbank 

10 DB verwaltet 

Warden von der Steuerung oder vom Leitstand beispielsweise einer Druckmaschine fOr 
die Diagnose relevante Informationen zur VerfQgung gestellt, konnen sie durch 
spezielle in dem Diagnose-Rechnerknoten integrierte Komponenten weiterverarbeitet 
werden. 

15 Die von der Bedlenoberflache am Diagnose-Rechnerknoten eingehenden Auftrage 
werden dort verarbeitet und in fur die entsprechenden Regler verstandliche Befehle 
umgesetzt Die Kommunikation zwischen Diagnose-Rechnerknoten und 
Kommunikatlons-Rechnerknoten mit angeschlossenem Regler erfolgt uber Ethernet 
und darauf aufsetzende XML-Protokolle. Am Kommunikations-Rechnerknoten werden 

20 die vom Application-Server empfangenen Auftrage ausgefQhrt und das Ergebnis an 
den Diagnose-Rechnerknoten zurQckgeschickt. 

Jeder der unterstQtzten Prozessrechnerknoten, beispielsweise Regler, muss eine xml- 
basierte Schnittstelle bieten. um dem Diagnose-Rechnerknoten den Zugriff auf die 
benotigten Daten zu ermOglichen. Dies kann z.B. mit Hilfe eines Kommunikations- 

25 Rechnerknotens („Kommunikations-PC") realisiert werden, der entweder im Prozess- 
Rechnerknoten integriert ist (z.B. b maXX 4600) oder dem Prozess-Rechnerknoten als 
Einsteckkarte zugefugt wird. Alternativ kann die xml-basierte Schnittstelle des Prozess- 
Rechnerknotens auch ohne Kommunikations-PC-Hardware als Teil des Diagnose- 
Rechnerknoten laufen. Die Kommunikation zwischen den Schnittstellen-Modulen auf 

30 dem Diagnose-Rechnerknoten und der Prozess-Rechnerknoten-Hardware erfolgt dann 
Qber proprietare Protokolle und RS232 oder Ethernet 
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Die eingangs genannten Anforderungen bedingen eine komponentenbasierte, verteilte 
Architektur des Diagnosesystems. GemaB den allgemeinen Grundsatzen der 
Softwareentwicklung werden die Datenerfassung, die Datenverarbeitung und - 
speicherung und die Benutzeroberflachen modularisiert und voneinander getrennt 

5 Dadurch wird eine Qbersichtliche und besser skalierbare Struktur erreicht, die leicint urn 
weitere Funktionaiitaten erweitert werden kann. Hierdurch kann gewahrleistet werden, 
dass das Diagnosesystem mit steigender Anzalil von Antrieben „mitwachsf 
(Skalierbarkeit). Durcli die Ven^^endung von Ethernet und TCP/IP fOr die 
Kommunikation zwiscfien den Kommunikations-PCs. dem Diagnose-Rechnerknoten 

10 und den Anwendungen steht eine wesentlich hOhere Bandbreite zur Datenubertragung 
zur VerfQgung. Daraus resultiert ein im Vergieicin zur eingangs genannten DE 196 14 
748 wesentlich schnelleres Diagnosesystem. 

Welter erieichtert die komponentenbasierte Struktur den grolJen Funktionsumfang des 
Diagnosesystems abzudecken. Fur jede Benutzergruppe kann eine eigens auf die 
15 Bedurfnisse zugeschnittene Bedienoberflache entwickelt werden, die auf die darunter 
liegende Infrastruktur (Diagnose-Rechnerknoten) zugreift. 

Durch die Trennung von Bedienoberflache und Implementierung der Funktionalit^t im 
Diagnose-Rechnerknoten kOnnen neue Anwendungen zukunftig mit weniger Aufwand 

20 entwickelt werden. Durch Nutzung moderner Softwaretechnologien kann das Internet 
als weltweit verfugbares und akzeptiertes Kommunikationsmedium genutzt werden. 
Damit ist es unerheblich, ob die ObenArachung der Aniage lokal vor Ort oder von einem 
anderen Ort, wie z.B. dem Serviceburo durchgefuhrt wird. Durch die Nutzung von 
gangigen Internetbrowsern for die Benutzeroberflachen wird der Installationsaufwand 

25 beim Anwender wesentlich reduziert und die HOrde fOr den Anwender das 
Diagnosesystem zu benutzen deutlich herabgesetzt. 

Die komponentenbasierte Architektur ermaglicht weiterhin die Unterstutzung von neu 
entwickeiten Verfahren zur Oberwachung und Diagnose von Antrieben. indem neue 
30 Funktionen als Komponente in den Diagnose-Rechnerknoten eingebunden werden. 



wo 2004/014022 




PCT/EP2003/050349 



Wesentliche Vorteile des erfindungsgemSlien Diagnosesystems bestehen 
insbesondere in folgendem: 

(1) Der Kunde hat durch die Weboberfiache einen universellen Zugriff auf die 
Diagnosefunktionen: 

• Die richtige Information zeitnaln am riclntigen Ort 

• Einfache Bedienoberflache durch Webbrowser 

• BenutzerfQhrung erieichtert die Bedienung und Konfiguration 

• Die Web-Oberfiache ist plattformunabhangig 

• Bedienung uber das Internet moglich. sofem gewunscht 

(2) Der Kunde bekommt fOr ihn aufbereitete Informationen Qber den Zustand der 
Aniage: 

• Informationsaufbereitung in Form von graphische Darstellungen 

• Vorbeugende Diagnose 

(3) Die wesentlich enAfeiterten Diagnosemoglichkeiten emnoglichen: 

• Erweiterte Oberwachung der Aniage 

• Einfachere Lokalislerung der Ursache im Fehlerfall 

(4) Die Funktionen zur InbetriebnahmeunterstOtzung emnoglichen: 

• Schnellere Inbetriebnahme Kostenreduzierung 

• Erhohte Qualitat der Inbetriebnahme durch definierte und dokumentierte 
Abnahmeprotokolle 

Eine Funktionsgruppe Softwareupdate ermOglicht das Installieren oder Aktualisieren 
einer Firmware des Prozess-Rechnerknotens beispielsweise zur Firmware. Alle 
durchgefQhrten Aktionen in dieser Funktlonsgaippe werden in einem Logfile erfasst. 
Voraussetzung far die Installation Oder Aktualisierung der Fimiware ist, dass die 
ausgewahlten Regler eine eindeutige Reglerkennung besitzen. Folgende Aktionen 
mOssen moglich sein: 
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1 . Antriebe auswahlen 

Der Benutzer wahit die zu aktualisierenden Antriebe aus eine Antriebsliste aus. 

2. Firmware auswahlen 

Der Benutzer wahIt die Firmware, die auf die zu aktualisierenden Antriebe 
5 geladen werden soli aus. 

3. DurclifQhren des Softwareupdates 

Nach der Anzeige eines Warnhinwelses wird das Softwareupdate durchgefuhrt. 

Eine Funktionsgruppe ^Events konfigurieren" bietet die MSgliclikeit beliebige 
10 Ereignisse in der Ereignisanzeige und im Logbuch aufzuzelchnen. Der im 
Kommunikations-PC des jeweils Prozess-Rechnerknotens vorhandene Event(Ereignis)- 
Broker wird mit Hilfe der unter genannten Funktionen konfiguriert, so dass er die 
gewunschten Parameterkombinatlonen auf das Eintreten des konfigurierten 
Ereignisses Qberwacfit Beim Eintreten des Ereignisses wird es an den Diagnose- 
15 Rechnerknoten geschickt und dort in der Ereignisanzeige angezeigt. Folgende 
Aktionen konnen beispielsweise moglich sein: 

1 . Antriebe auswahlen 

Der Benutzer wahIt die Antrieb aus. fur die ein Event konfiguriert Oder geioscht werden 
soli. 

20 2. Event konfigurieren 

Der Benutzer konfiguriert ein Ereignis mit Hilfe eines Konfigurations-Wlzards 

3. Event loschen 

Der Benutzer loscht einen Event aus eine Liste mit laufenden Events. 

StandardmaBig vorhandene Events, wie z.B. Fehler konnen nicht geioscht 
25 werden. 



4. Eventkonfiguration zum Antrieb schicken 

Der Benutzer schickt den konfigurierten Event zu einer Antriebsauswahl und 
aktiviert ihn. 
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Eine Funktionsgruppe „Skripte" bietet die Moglichkeit komplexe Diagnosefunktionen 
durchzufuhren. Urn komplexe Abfragen von Parametem zu realisieren konnen PERL- 
Skripte geschrieben werden, die auf den entsprechenden Kommunikations-PC 
geschickt werden und dort ausgeftlhrt werden. Folgende Aktionen sollen m6glich sein: 

1 Laden des Skripts auf den Server 

Der Benutzer ladt das Skript von dem Kommunikations-PC eines Antriebs auf den 
Server. 

2 Laden des Skripts zum Antrieb 

Der Benutzer ladt ein aus einer Liste ausgewShltes Skript auf einen ausgewahlten 
Antrieb. 

3 Skript editieren 

Der Benutzer editiert ein Skript 

4 Ausfuhren des Skripts auf dem Kommunikations-PC 
Der Benutzer startet das Skript auf einem Antrieb. 

Nachfolgend wird ein Qberblick Qber die Architektur des Diagnose-Rechnerknotens des 
Diagnosesystems gegeben. Figur 1 zeigt eine detailllerte Struktur des 
Diagnosesystems Sie besteht im wesentlichen aus drei Ebenen: 

Client-Rechnerknoten mit Bedienoberflachen: 

Alle Funktionalitaten des Diagnosesystems konnen Qber die Bedienoberflachen 
bedient werden. FQr den Benutzer des Diagnosesystems soli es keinen Unterschied 
machen, ob er sich im lokalen Netz an der Aniage befindet oder Qber das Internet oder 
eine Telefon-Einwalilverbindung mit dem Application-Server verbunden ist. 

Diagnose-Rechnerknoten 

Dieser stellt den Kern der gesamten Anwendung dar. Seine Funktionalitat ist in 
verschiedene Komponenten (Manager) unterteilt. Jeder Manager ist in sich 
abgeschlossen und stellt seine Funktionalitat der webbasierten Bedienoberfiache oder 
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anderen Serverkomponenten zur VerfQgung. Alle fQr die Funktlon des Managers 
notwendigen Daten werden in der angeschlossenen Datenbank gespelchert. Um die 
Kapselung und Konsistenz dieser Daten zu gewahrleisten kann auf diese 
Datenbestande nur Qber die vom IVIanager zur VerfDgung gestellten Funktionen 
zugegriffen werden. Dadurch wird aucii sichergestelit, dass eine Anderung an der 
Datenbankstruktur eines Managers nicht unbedlngt Anderungen an anderen Managern 
nach sicli zieht. 

Um die Funktionalitaten der Manager den Bedienoberflaclien zur VerfOgung zu stellen 
muss eine geeignete Infrastruktur geschaffen werden. (Tomcat Servlet-Container) FQr 
die Kommunikation mit der Weboberfiaclie zur Inbetriebnatime, Uberwaclnung und 
Diagnose soli ein Apache Webserver eingesetzt werden. Dieser stellt HTML-Seiten zur 
VerfQgung, in die Java-Applets eingebettet sind. Die auf der Oberfiache 
anzuzeigenden Daten werden mit Hilfe von Soap (Simple Object Appiication-Protokoll) 
zu den entsprechenden Modulen Qbertragen. Die Benutzeroberflache ruft z.B. eine 
Funktion des Aniagen-Managers auf. Die zu ubergebenden Parameter und die 
Bezeichnung der Funktion wird mit Hilfe des Soap Protokolls auf das Intra- oder 
Internet geschickt. Um die Transparenz gangiger Firewalls zu gewahrleisten. wird der 
Funktionsaufruf in Form eines HTTP-Telegramms verschickt. Ein Webserver auf der 
Seite des Application-Servers empfangt die HTTP-Telegramme mit dem Soap-lnhalt 
und leitet sie an den Soap-Handler waiter. Der Soap-Handler im Tomcat-Servlet 
Container decodiert die Anfl-age und ruft die gewunsclite Funktion aus dem Anlagen- 
Manager auf. Die Funktion wird ausgefDhrt und die Ruckgabewerte wiederum in das 
Soap Protokoll umgesetzt und als HTTP-Telegramm an die Oberfiache geschickt. 

Eine wesentliche Eigenschaft eines Diagnose- und ObenA^achungssystems 1st, dass der 
Benutzer Qber an der Aniage auftretende Ereignisse zeitnah informiert wird. Dies stellt 
fQr die oben gezeigte Architektur eine Schwierigkeit dar, da sowohl fQr die 
Kommunikation Qber Soap als auch fQr die HTML-Selten eine ereignisbasierte 
Benachrichtigung nidit vorgesehen ist Als Abhilfe mOssen an der Aniage auftretende 
Ereignisse. wie z.B. das Auftreten eines Fehlers oder das Update eines 
Parametenwertes in einer Oberfiache, Qber einen Event-Kanal. den 
Benutzeroberfiachen mitgeteilt werden oder standig gepollt werden. 
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Prozessrechner-Knoten 

Die Prozess-Rechnerknoten-Ebene stellt dem Diagnose-Rechnerknoten die Daten von 
den Prozess-Rechnerknoten zur Verfugung. Es soil der Prozess-Rechnerknoten 
angebunden werden. Wie bereits angedeutet, besteht der Diagnose-Rechnerknoten 
aus verschiedenen gekapselten Serverkomponenten (Manager), die iiire 
Funktionalitaten uber den Tomcat-Servlet-Container der BenutzeroberfiSclie 
beziehungsweise Ciient-Rechnerknoten zur Verfugung stellen. Durch die 
komponentenbasierte Struktur soli siclnergestellt werden, dass der Funktionsumfang 
des Diagnosesystems enweitert werden kann. Die Manager sind als Java-Komponenten 
realisiert. Im Folgenden werden die einzelnen Manager beschrieben. 

Der Aniagen-Manager enthait alle notwendigen Daten uber die Konfiguration der 
Aniage. Dies beinhaltet Daten uber die in der Aniage vorhandenen Komponenten, 
Gruppierung der Komponenten, Adressen etc. Es soilen Funktionalitaten zur VerfQgung 
gestellt werden, die die Darstellung der Aniagenkonfiguration in Form verschiedener 
Obersichtsbilder eriauben. Weiterhin sollen alle Dokumentationen zu den in der Aniage 
entiialtenen Daten zur VerfQgung gestellt werden. 

Beim Entwurf des Aniagen-Managers ist darauf zu achten, dass mit Hilfe der 
FunktionalitSiten dieser Komponente beliebige Aniagen im Bereich der Antriebstechnik 
besclirieben werden kOnnen. 

Der Ereignis-Manager verwaltet alle im Diagnosesystem auftretenden Ereignisse wie 
z.B. Felilermeldungen oder Wartungsereignisse. Er sammelt alle aufgetretenen 
Ereignisse in Form von LogbQchem und stellt sie dem Benutzer in einer 
konfigurierbaren Darstellung zur Verfugung. Weiterhin besitzt der Ereignis-Manager 
Funktionen mit deren Hilfe beliebige EreignisubenA/achungen definiert werden konnen, 
die dann vom Ereignis-Manager auf den entsprechenden Reglern konfiguriert werden. 
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Der Aufeeichnungs-Manager stellt Funktionen zur VerfOgung mit deren Hilfe beliebige 
Parameter von beliebigen Reglern aufgezeichnet werden kOnnen. Er bietet 
verschiedene Aufzeichnungstypen die von Benutzer konfiguriert werden konnen. Alle 
5 bei einer Aufeeichnung anfallenden Daten werden vom Aufeeichnungs-Manager in 
einer Datenbank gespeiclnert und auf Anforderung hin anderen Modulen, wie z.B. 
einem Graphik-l\^odul der Oberfiaclne zur VerfQgung gestellt. 

Alle Funktionalitaten im Diagnosesystem sind gegen unautorisierten Zugriff geschutzt. 

Jeder Benutzer hat eine Benutzerkennung und gehOrt zu einer Benutzergruppe, die 
10 ihm ein Rechteprofll for den Zugriff auf die Funktionalitaten der Manager ermSglicht. 

Diese Informationen werden im Benutzer-Manager konfiguriert und abgespeichert. 

Jede Funktion In den Managern hat eine eindeutige Kennung. Will ein Benutzer auf 

eine Funktion zugreifen, wird zunachst am Benutzer-Manager nachgefragt ob der 

Benutzer die entsprechenden Rechte fOr das Ausfuhren dieser Funktion besitzt. Die 
15 Datenbank in der die Benutzerdaten abgelegt werden soli durch VerschlQsselung vor 

unberechtigtem Zugriff geschutzt werden. 

Der Logging-Manager sammelt alle Logging-Daten von den angeschlossenen Reglern 
und speichert derern Log- und Debug-Nachrichten in einer Datenbank oder in 
20 rollierenden Logfiles ab. 

Der Kommunikations-Rechnerknoten beziehungsweise Kommtinlkatlons-PC gema& 
Figur 5 ubemimmt die Kommunikationsaufgaben zwischen dem Prozess- 
Rechnerknoten und der AulXenwelt. Nachfolgend wird die Softwarestruktur fQr die 
25 Kommunikation zum Prozess-Rechnerknoten beschrieben. 

Jedes Gerat, das mit dem Prozess-Rechnerknoten kommunizieren soil, muss ihn uber 
eine geeignete Software-Schnittstelle auf dem Kommunikations-PC ansprechen. Mit 
Hilfe des Kommunikations-PCs kann beinahe jede Software-Schnittstelle, die auf 
Ethernet oder einer seriellen Schnittstelle basiert, realisiert werden. Nachfolgend wird 
30 die Softwarearchitektur auf dem Kommunikations-PC beschrieben. Eine Einordnung in 
das Gesamtkonzept ist den obigen AusfQhrungen zu entnehmen. Die Figur 5 zeigt die 
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Softwarestruktur auf dem Kommunikations-PC beziehungsweise Prozess- 
Rechnerknoten. 

Jede Funktionalitat, die vom Prozess-Rechnerknoten der AuSenwelt zur Verfugung 
gestellt warden soil, ist in einem Softwaremodul (Informations-Broker Oder Manager) 
realisiert. Z.B. stellt der Informations-Broker ^Parameter" eine Parameterschnittstelle 
zur VerfQgung uber die beliebige Parameter des Prozess-Rechnerknotens gelesen 
und geschrieben werden konnen. Der Informations-Broker „Fehler und Events" stellt 
beliebige Ereignisse und Fehler nach auBen dar. Die beiden Informations-Broker 
„Parameter-Bedarfsdaten" und „Zyklische Sollwerte" eriedigen die Kommunikation 
mil der Steuerung. Sie sind nur auf den Reglern vorhanden, die den Master im 
Sercos-Ring bilden und somit mit der Steuerung kommunizieren mussen. Der 
Informations-Broker „Software-Download'' stellt Funktionen fur einen automatischen 
Up- und Download der Regler-Firmware bereit. Ein (nicht gezeichneter) Parameter- 
Manager dient zur internen Verwaltung der Reglerparameter auf der Flashkarte. Er 
ist fur die Kommunikation mit der AuRenwelt nicht relevant. 

Die Kommunikation der Informations-Broker „Parameter", „Fehler und Event" sowie 
„Softwaredownload" mit der Audenwelt erfolgt uber XML-basierte Protokolle. Alle 
Anfragen bzw. Antworten werden in. mit Hilfe eines XML-Schemas definierten, XML- 
Nachrichten ubertragen. 

Jeder der vorhandenen Broker kann gleichzeitig mehrere Anfragen von einem oder 
verschiedenen Clients bearbeiten. Im Wesentlichen kommuniziert der 
Kommunikations-PC des Prozess-Rechnerknotens mit der Steuerung und dem 
Diagnose-Rechnerknoten. In der Kommunikation mit einer SPS-Steuerung muss 
sichergestellt werden. dass die Nachrichten in jedem Fall ohne unnOtigen Zeitverzug 
an einem Prozessor des Prozess-Rechnerknotens verarbeitet werden, da sie ftlr den 
Betrieb der Aniage von wesentlicher Bedeutung sind. Nachdem die Anfragen auf 
dem Prozessor des Prozess-Rechnerknoten nur sequentiell verarbeitet werden 
konnen, muss die MOglichkeit bestehen. Anfragen von der SPS-Steuerung vorrangig 
zu bearbeiten. Dies soli durch Vergabe von Prioritaten far die Anfragen sichergestellt 
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werden. Jede Anfrage an einen der Broker am Kommunikations-PC ist mit einer 
Prioritat versehen. GemaR dieser Prioritat wird die Anfrage bevorzugl oder 
nachrangig behandelt. 

Neben den Informations-Brokern gibt es weitere, zum Teil optionale, Softwaremodule 
auf dem Kommunikations-PC: 

• Ein Logging-Server empf^ngt Log- und Debugnachrichten von den 
Informations-Brokern und stellt sie der AufJenwelt zur Verfugung. 

• Ein Webserver bietet eine einfache Weboberflache zur Bedienung und 
Konfiguration. 

Ein FTP-Server dient zum einfachen Up- und Download von Firmware auf den 
Prozess-Rechnerknoten. 
' Ein Client zur Zeitsynchronisation sorgt fur eine ubereinstimmende Zeit auf 
alien Kommunikations-PCs einer Aniage. 

• Mit Hilfe eines Perl-Interpreters konnen beliebige Skripte mit Diagnose- oder 
Steuerungsfunktionalitaten ausgefuhrt werden. 

• Der Konfigurations-Manager eriedigt das Starten wichtiger Dienste (z.B. 
automatische Konfiguration einer Ereignisuberwachung fur einen Fehler im 
technisch-physikalischen Prozess) sowie die VenA^altung der 
Konfigurationsdaten der einzelnen Softwaremodule. 

• Ein Telnet-Zugang steht fQr Wartungszwecke zur Verfugung. 

Im Folgenden werden die Softwaremodule des Kommunikations-PCs bechrieben. 

Aufgabe des Informations-Brokers .Parameter^ ist die Bereitstellung einer XML- 
basierten Parameterschnittstelle fQr den Zugriff auf die Parameter des Prozess- 
Rechnerknotens. Als Protokoll kommt ein mit Hilfe eines XML-Schemas definlertes 
xml-basiertes Protokoll zum Einsatz, welches Qber TCP/IP mit dem Client 
kommuniziert. Aus der Sicht des Clients sollen folgende Funktionen gegeben sein: 



Lesen von Parametern 
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Der Informations-Broker „Parameter" soil eine Gruppe von beliebigen Parametern 
vom Prozessor des Prozess-Rechnerknotens lesen konnen. Hierbei soil neben dem 
einmaligen Lesen ein zyklisches Lesen von Parametern mCglich seln. Das Inten/all 
zwischen den Lesevorgangen und die Anzahl der Lesevorgange sollen vom Client 
5 einsteilbar sein. 

Schreiben von Parametern 

Der Informations-Broker ,.Parameter" soil eine Gruppe von beliebigen Parametern auf 
den Prozess-Rechnerknoten schreiben konnen. 

Aufgabe des Informations-Brokers „Fehier und Events" ist die Bereitstellung einer xml- 
basierten Schnittstelle uber die ein Client uber am Regler auftretende Ereignisse 
informiert wird. ohne dass er standig am Regler anfragen muss. Als Protokoil kommt 
ein mit Hilfe eines XML-Schemas definiertes xml-basiertes Protokoil zum Einsatz, 
welches uber TCP/IP mit dem Client kommunizlert. Aus der Sicht des Clients sollen 
folgende Funktionen verfugbar sein: 

Konfigurieren einer EreignisOberwachung 

Am Informations-Broker „Event" soil es moglich sein, beliebige Eintrittsbedingungen fur 
20 ein Ereignis zu definieren, bei deren EIntreten eine Nachricht an den Client verschickt 
wird. Falls das Ereignis eingetreten ist. sollen zusatzlich zu den an der 
Eintrlttsbedingung beteiligten Parametern noch weitere Parameter vom Regler 
abgefragtwerden konnen. 

Ein erfolgreich entgegen genommener Auftrag soil vom Broker bestatigt werden. 

25 

Der Informations-Broker „Event" soli umfangrelche Funktionalitaten besitzen die dem 
Client weltreichende MOglichkeiten bieten, Eintrittsbedingungen zu bilden. Eine 
Eintrittsbedingung soil aus mehreren Teilbedingungen zusammengesetzt sein, die 
miteinander logisch UND oder ODER verknQpft werden konnen. Innerhalb jeder 
30 Teilbedingung kann der aktuell gelesene Wert des Parameters entweder mit einem. in 
der Konfigurationsnachricht mitgeschickten Vergleichswert oder mit dem letzten 
gelesenen Parameterwert verglichen werden. Optional soli ein Toleranzlimit 
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berucksichtigt werden konnen, das mit dem Vergleichswert verrechnet wird. Es sollen 
far den Vergleich sowohl alle logischen Operatoren (<, >. <=. >=. !=) sowie der 
Vergleich mit einer Bitmaske realisiert werden. Zus^zlich soil fOr jede Teilbedingung 
ein Triggermodus berucksichtigt werden, der angibt, ob das Ereignis beim erstmaligen 
Eintreffen der Ereignisbedingung, beim Verschwinden einer bereits eingetretenen 
Bedingung oder in beiden Fallen gesendet werden soil. 
Melden eines Ereignisses 

Beim Eintreffen der konfigurierten Ereignisbedingung soli eine XML-Nachricht an den 
Client gesendet werden. 

Beenden einer Ereignisuberwachung 

iVIit Hilfe einer dafur vorgesehenen XML-Nachricht kann eine laufende 
EreignisQberwachung beendet werden. 

Abfrage des Status einer Ereignisuberwachung 

Mit Hilfe einer dafQr vorgesehenen XML-Nachricht kann der Client beim Informations- 
Broker „ Event" anfragen. ob eine Ereignisuberwachung lauft oder bereits beendet 
wurde. 

Ein Unterschied zum Informations-Broker ^Parameter" ist, dass zum Client keine 
permanente Socket-Verbindung besteht. Nach der Konfiguration des Events wird diese 
abgebaut und erst beim Auftreten des konfigurierten Events wieder aufgebaut. Hierfur 
muss auf der Selte des Clients ein entsprechender Server-Port zur Verfugung stehen. 

Der Informations-Broker „Zyklische Sollwerte" erledigt einen Teil der Kommunikation 
mit der Steuerung. Er kommt insbesondere bel Druckmaschinen Anwendungen zum 
Einsatz, sofern es sich um einen Prozess-Rechnerknoten beziehungsweise Regler 
handelt, der Sercos-Master in einem Antriebsring ist 

Aufgabe des Informations-Brokers „Zyklische Sollwerte" ist es, den Regler in 
regelmalSigen Zeitintervallen mit neuen Sollwerten von der Steuerung zu versorgen. 
Dabei empfangt er die von der Steuerung gesendeten Telegramme und leitet sie an 
den Regler weiter. Er soil folgende Fahlgkeiten besitzen: 



wo 2004/014022 




PCT/EP2003/050349 



Empfang der Sollwert-Telegramme von einer oder mehreren Steuerungen 
Der Informations-Broker .,Zyklische Sollwerte" soli in der Lage sein, Sollwert- 
Telegramme von einer oder mehreren Steuerungen zu empfangen. Die Kommunikation 
5 mit der Steuerung kann uber ein proprietares Protokoll und/oder das Protokoll UDP/IP 
laufen. 

Weiterleitung der Sollwerte an den Regler 

Alle von einer Steuerung BPS empfangenen Sollwerttelegramme sollen mit der 
10 hochsten Prioritat an den Prozess-Rechnerknoten beziehungsv\/eise Regler 
weitergeleltet werden. 

Monitoring der Sollwert-Telegramme 

FQr Diagnosezwecke soli es moglich sein, die ankommenden Telegramme von der 
15 Steuerung neben der Weiterleitung an den Regler zusatzlich auch an das 
Diagnosesystem weiterzugeben. 

Der Informations-Broker „Parameter-Bedarfsdaten" erledigt einen Teil der 
Kommunikation mit der Steuerung. Er kommt insbesondere bei Druckmaschinen- 
20 Anwendungen zum Einsatz, sofern es sich urn einen Prozess-Rechnerknoten oder 
Regler handelt, der Sercos-Master in einem Antriebsring ist 

Aufgabe des Infomiations-Brokers „Parameter-Bedarfsdaten" ist es einer oder 
mehreren Steuerungen beliebige Parametenfl/erte zeltnah zur VerfQgung zu stellen. Er 
soil folgende Fahigkeiten besitzen: 

25 Lesen von Parametern 

Ein Steuerungsclient schickt beliebige Parameter in einem Anforderungstelegramm an 
den Informations-Broker. Dieser fragt die Parameterwerte mit einer hohen Prioritat vom 
Regler ab und sendet ein Antworttelegramm an den Steuerungsclient zuruck. FQr die 
Kommunikation mit dem Steuerungsclient kann ein proprietares Protokoll und/oder 

30 TCP/IP zum Einsatz kommen. 



Monitoring der Anforderungstelegramme 
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Ftir Diagnosezwecke soli es moglich sein, die ankommenden Telegramme von der 
Steuerung neben der Welterleitung an den Prozess-Rechnerknoten oder Regler 
zusatzlich auch an das Diagnosesystenn weiterzugeben. 

Aufgabe des Infomnatlons-Brokers ..Softwaredownload" ist die Gbertragung der 
Regierfirmware sowie kompletter Datensatze zwischen dem Diagnose-Rechnerknoten 
und dem Regler. Die Gbertragung der Daten erfolgt mit Hilfe des ftp-Protokolls. Er soil 
folgende Fahigkelten besitzen: 

Download einer Regierfirmware auf den Regler als Prozess-Rechnerknoten 
Der Download von Regierfirmware erfolgt in zwei Schritten: Zunachst wird mit Hilfe 
eines ftp-Clients die Firmware In ein Verzeichnis auf der Flashkarte des 
Kommunikations-PCs ubertragen. Im zweiten Schritt wird der Informations-Broker 
„Soflwaredownload" mit Hilfe eines XML-Telegramms angewiesen die 
Booteinstellungen des Reglers so zu verandern, so dass beim nachsten Booten des 
Reglers die neue Firmware gestartet wird. 

Upload einer Regierfirmware vom Regler als Prozess-Rechnerknoten 

Der Upload einer Regierfirmware erfolgt direkt uber das ftp-Protokoll. Hierbei ist keine 

Unterstutzung von Seiten des Informations-Brokers „Softwaredownload" notwendig. 

Download eines kompletten Datensatzes 

Wie beim Download einer Regierfirmware erfolgt auch der Download eines Parameter- 
Datensatzes in zwei Schritten: 

Zunachst wird mit Hilfe eines ftp-Clients der Datensalz in ein Verzeichnis auf der 
Flashkarte des Kommunikations-PCs Ubertragen. Im zweiten Schritt wird der 
Informations-Broker „Softwaredownload" mit Hilfe eines XML-Telegramms angewiesen 
die Einstellungen des Reglers so zu verSndern, so dass beim n^chsten Booten des 
Reglers der neue Datensatz berOcksichtigt wird. 



Upload eines kompletten Datensatzes 
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Der Upload eines Datensatzes erfolgt direkt Qber das ftp-Protokoll. Hierbei ist keine 
UnterstUtzung von Seiten des Informations-Brokers „Softwaredownload" notwendig. 

Aufgabe des Connection-Managers ist es. die Schnittstelle zum Regler 
beziehungsweise Prozess-Rechnerknoten zu venwaiten. Hierbei soli es mogllch sein, 
verschiedene physikalische Schnittstellen zu verwalten. (z.B. seriell. Ethernet Oder SRI) 
Jede Anfrage an den Connection-Manager Ist mit einer von 5 Prioritatsstufen versehen. 
Anfragen mit der hoclisten Prioritat werden vom Connection-IVIanager vor alien 
weiteren anstehenden Anfragen an den (digitalen Signal-)Prozessor Prozess- 
Rechnerknotens geschickt. Anfragen mit niedriger PrioritSt werden immer nach alien 
anderen anstehenden Auftragen behandelt. Hierdurch kann sichergestellt werden, 
dass ein Auftrag mit hochster Prioritat -z.B. von der Steuerung- in jedem Fall als 
nachste Anfrage auf dem Prozess-Rechnerknotens bearbeitet wird. 

Im Prozess-Rechnerknoten ist als Speichermittel eine Flash-Karte aufgrund der 
besseren Unterstutzung durch den Intel PXA 255 dem Kommunikations-PC 
zugeordnet. Trotzdem muss for den Prozess-Rechnerknoten beziehungsweise Regler 
eine Mogiichkeit bestehen Parameter von der Flash-Karte zu lesen sowie auf die 
Flash-Karte zu schreiben. Dies wird mit Hilfe des Parameter-Managers gewahrletstet. 

Weitere Dienste auf dem Kommunikations-PC 
Logging Servers 

Alle Meldungen, die in den Informations-Broker-Prozessen erzeugt werden, werden 
fonnatiert und an die Konsole, in ein Logfile oder eine Nachrichtenwarteschlange des 
Log-Servers geschrieben. Von diesem Log-Server k6nnen die Nachrichten dann zu 
beliebigen Servem / Rechner verschickt werden. 

Um die spatere automatische Auswertung der Logfiles zu ermOglichen, werden 
verschiedene Nachrichtentypen definiert, die die Interpretation der Nachrichten 
erieichtem. (z.B. Debug, Daten. Enror ...) 
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Skriptunterstutzung 

Mit Hilfe der Skriptunterstutzung auf dem Kommunikations-PC soli eine flexible und frei 
programmierbare Schnittstelle geschaffen werden, nnit der auch zukQnftige 
Anforderungen an Oberwachung und Diagnose abgedeckt werden sollen. Mit Hilfe 

5 eines Perl- Interpreters kftnnen beliebige Skripte auf dem Kommunikations-PC 
ablaufen, die auf die Funktionalitaten der Informations-Broker ^Parameter" und „Fehler 
und Events" zugreifen. So kOnnen komplexere Uberwachungsfunktionen lokal auf dem 
Kommunikations-PC ausgefuhrt werden ohne daB eine Belastung des Netzwerks durch 
Obertragung von Daten stattfindet. Die Skripte werden mit Hilfe des ftp-Servers auf 

10. dem Kommunikations-PC ubertragen oder sind dort schon als Tail der Software 
vorhanden. 

Wegen der hohen Anforderungen an Performance und Systemressourcen des 
Kommunikations-PCs soil die Skriptunterstutzung nur fur spezielle Diagnoseaufgaben 
verwendet werden. 

15 

Zeitsynchronisation, FTP-Server, Telnet 

FQr die Synchronisierung der Systemzeiten sollen alle Kommunikations-PCs ihre 
Systemzeit regelmaiiig uber einen auf dem BAUDIS Server laufenden Zeitserver 
synchronisieren. 

20 Der FTP-Server und der Telnet-Zugang dienen fGr das Software-Update des 
Kommunikations-PCs und zur Wartung. 

Wahrend des Betriebs des Antriebssystems entstehende Diagnosedaten (z. B. Fehler 
Oder Dlagnoseinformationen wie z. B. Temperatur, Geschwindigkeit, Schleppfehler. 
25 Regelabweichung) werden vom Kommunikations-PC auf dem Prozessrechnerknoten 
bzw. Antriebsregler gepollt und in ein xml-basiertes Protokoll umgewandelt. Der 
Kommunikations-PC stellt die Diagnosedaten ereignisbasiert (Informations-Broker 
„Event") Oder anfragebasiert (Informations-Broker ..Parameter) dem 
Diagnosereclinerknoten zur VerfQgung. 

30 

In den Managem des Diagnoserechnerknotens werden die Diagnosedaten von den 
Kommunikations-PCs der Antriebsregler geholt bzw. ereignisbasiert empfangen und 
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weiterverarbeitet (z. B. Abspeichern in der Datenbank, Umrechnen etc.). Sollen 
Diagnosedaten auf der Benutzeroberflache angezeigt werden, leitet der Manager die 
Diagnosedaten an die entsprechende Komponente im Sen/let Container weiter. Dort 
vy^erden die Daten aufbereitet, so dass sie mit Hilfe von anfragenbasierter 
5 Kommunikation (Polling) oder mit Hilfe von ereignisbasierter Kommunikation (Event- 
Kanal) uber die Datenfernverbindung zu den Java-Applets, die in der 
Benutzeroberfiachen eingebettet sind, ubertragen werden konnen. 

Figuren 6 und 7 zeigen webbasierte Bedienoberflachen, welche die benOtigten 

10 Diagnose-lnformationen fur die Benutzer grafisch aufbereiten. Dadurch wird das 
erfindungsgemaBe Diagnosesystem zu einem Instrument, das die 
Maschinenverfugbarkeit erhoht und auch komplexe AnIagen mit einer Vielzahl von 
Antrieben beherrschbar macht. So kann mit Bedienoberflachen nach Art des In Figur 7 
und 8 gezeigten der Maschinenleltstand mit Daten fur den aktuellen Maschinenstatus, 

■15 Oder die Produktionsleitung mit statistischen Daten zur Maschinenverfugbarkeit und zu 
Wartungszyklen versorgt werden. Aber auch der Maschinenhersteller oder der 
Antriebsausruster kann auf eine Aniage mit einer Vielzahl physikalisch-technischer 
Prozesse so komfortabel zugreifen, um im Servicefall schnelle und effiziente Diagnose 
urid Fehlerbeseitigung zu gewahrleisten. Dies wird durch den Einsatz moderner Web- 

20 Technologten bzw. webbasierter Bedienoberflachen mit der ihnen innewohnenden 
Flexibilitat ermOglicht. Vorteilhaft kann so die Weboberflache auf jedem beliebigen 
Client-Rechner laufen, unabhangig vom jeweiligen Client-Betriebssystem. Eine 
Installation einer fQr das Diagnosesystem spezifischen Bedienoberfiache auf dem 
Client-Rechnerknoten entfailt. Die webbasierten Bedienoberflachen sind aufgrund der 

25 weiten Verbreitung durch das Internet vom Benutzer in gewohnter und damit leichter 
Weise bedienbar. Mit vertretbarem Aufwand kann die Bedienoberflache an 
KundenwOnsche angepalit werden (z. B. SprachunterstGtzung). 

Bezugszeichenllste 



30 

1 Achse 

2 Elektromotor 
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3 Wechselrichter 

4 Prozessrechnerknoten 

5 Kommunikationsrechnerknoten 

6 Schaltschrank 

5 SPS Steuerungsrechnerknoten 
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Patentanspriiche 
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Rechner-Netzwerk zur Konfiguration, Inbetriebnahme, Oberwachung, Fehler- 
Diagnose und/oder -Analyse mehrerer technisch-physikalischer Prozesse, 
insbesondere elektrischer Antriebsvorgange, die unter der Steuerung, Regelung 
und/oder Oberwachung durch mehrere Prozessrechnerknoten (4) ablaufen, 
welche uber wenigstens ein gemeinsames Kommunikationssystem mit 
wenigstens einem Diagnoserechnerknoten verbunden sind, in dem ein oder 
mehrere Konfigurations-, Uberwachungs-, Diagnosedienste und/oder -funktionen 
implementiert sind, die den Prozessen und/oder den Prozessrechnerknoten (4) 
und/oder den darin ablaufenden Datenverarbeitungsprozessen zugeordnet sind, 
dadurch gekennzeichnet, dass das gemeinsame Kommunikationssystem mit 
dem Ethernet oder einem sonstigen, asynchron und/oder mit einem 
stochastischen Zugriffsverfahren arbeitenden Bus- oder Kommunikationssystem 
realisiert ist. 

Netzwerk nach Anspruch 1, dadurch gekennzeichnet. dass dem Ethernet oder 
dem sonstigen Bus- oder Kommunikationssystem und wenigstens einem der 
Prozessrechnerknoten (4) ein Kommunikationsmodul oder -rechnerknoten 
zwischengeschaltet ist, das beziehungsweise der den Prozessrechnerknoten (4) 
an das Ethernet oder sonstige Bus- oder Kommunikationssystem anbindet. 

Netzwerk nach Anspruch 2, dadurch gekennzeichnet dass das 
Kommunikationsmodul oder der Kommunlkationsrechnerknoten (5) zur anfrage- 
oder ereignisbasierten Kommunikation mit dem Diagnoserechnerknoten 
ausgebildet ist. 

Netzwerk nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das 
Kommunikationsmodul oder der Kommunlkationsrechnerknoten (5) zur 
Kommunikation mit dem Diagnoserechnerknoten Qber XML-Protokolle und/oder 
ais XIVIL-basierte Schnittstelle ausgebildet ist. 
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5. Netzwerk nach einem der AnsprQche 2 bis 4, dadurch gekennzeichnet, dass das 
Kommunikationsmodul ganz oder teilweise auf der Hardware des 
Prozelirechner- und/oder Diagnoserechnerknotens ablauffahig ist. 

6. Netzwerk nach einem der AnsprQche 2 bis 4, dadurch gekennzeichnet, dass der 
Kommunikationsrechnerknoten (5) als Zusatz-Baukomponente fur den jeweiligen 
Prozessrechnerknoten (4) ausgebildet ist. 

7. Netzwerk nach einem der AnsprQche 2 bis 5, dadurch gekennzeichnet. dass zum 
jeweiligen Datenaustausch jedem Kommunikationsmodul ein 
Prozessrechnerknoten (4) und/oder technisch- physikalischer Prozess oder 
jedem Kommunikationsrechnerknoten (5) zumindest ein technisch-physikalischer 
Prozess oder ein Prozessrechnerknoten (4) zugeordnet ist, 

8. Netzwerk nach einem der AnsprQche 2 bis 5 oder nach Anspruch 7, dadurch 
gekennzeichnet, dass wenigstens einer der Kommunikationsrechnerknoten (5) 
mit mehreren Prozelirechnerknoten vorzugsweise uber ein. serielles 
Kommunikationssystem verbunden ist. 

9. Netzwerk nach einem der AnsprQche 2 bis 8, dadurch gekennzeichnet, dass das 
Kommunikationsmodul oder der Kommunikationsrechnerknoten (5) mit 
Funktlonalitaten zur Fehlersuche oder Diagnose im Bereich wenigstens eines 
der ProzeBrechnerknoten und/oder technisch-physikalischen Prozesse versehen 
Ist. 

10. Netzwerk nach einem der vorangehenden AnsprQche, dadurch gekennzeichnet. 
dass der Diagnoserechnerknoten zur Bereitstellung oder Unterstutzung 
webbasierter Bedienoberflachen insbesondere Qber DatenfernObertragung oder 
ein Weitverkehrsnetz ausgebildet und mit den Bedienoberflachen entsprechende 
Funktionskomponenten versehen ist. 



wo 2004/014022 




PCT/EP2003/050349 



11. Netzwerk nach einem der vorangehenden AnsprQche, gekennzeichnet durch 
eine Strukturierung entsprechend der Client/Server-Architektur mit dem 
Diagnoserechnerknoten als Server. 

5 12. Diagnoserechnerknoten fQr ein Netzwerk nach Anspruch 11 und gegebenenfalls 
2, ausgebildet als Server mit Schnittstellen zu wenigstens einer Datenbank, zur 
Kommunikation mit den Kommunikations-. und/oder ProzeBrechnerknoten und 
sonstigen Client-Rechnerknoten, wobel die eine Oder mehreren Schnittstellen zu 
den sonstigen Client-Rechnerknoten mit einem Servlet-Container reaiisiert sind, 

10 welcher der Obertragung von Diagnosedaten, die aus den Schnittstellen zur 

Kommunikation mit den Kommunikations- und/oder Proze&rechnerknoten 
erhaltlich sind, an die Clientknoten dient, und die eine oder mehreren 
Schnittstellen zu den Kommunikations- und/oder ProzelSrechnerknoten 
beziehungsweise Kommunikatinsmodulen auf der Basis des Ethernet reaiisiert 

15 sind, gekennzeichnet durch einen Diagnosekanal, der gebildet ist mit 

folgendem: 

mit einer oder mehreren der den Kommunikations- und/oder 
Prozessrechnerknoten (4) zugeordneten Ethernet-Schnittstellen; 

mit einem Ereignis-Mangementmodul mit Datenbank-Zugriff, welches zur 
20 Verarbeitung der an den Ethernetschnittstellen erhaltenen Diagnosedaten 

ausgebildet ist; 

mit einem auf der Basis des Servlet-Containers angelegten Ereignis- 
Oberwachungsmodul. das Ausgangsdaten aus dem Ereignis-Managementmodul 
einem oder mehreren Applets auf externen Client-Rechnerknoten zur Verfugung 
25 Stent. 

13. Diagnoserechnerknoten nach Anspruch 12, dadurch gekennzeichnet, dass dem 
Servlet-Container ein Webserver zur Generierung und Weiterubertragung von 
HTIVlL-Seiten aus vom Servlet-Container erhaltenen Daten nachgeordnet ist 

30 

14. Diagnoserechnerknoten nach Anspruch 12 oder 13. dadurch gekennzeichnet 
dass die Schnittstellen zur Kommunikation mit den Kommunikations- und/oder 
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ProzeBrechnerknoten tiber XML-Protokolle, und/oder die Schnittstellen zur 
Kommunikation mit den Client-Rechnerknoten uber das SOAP (Simple Object 
Process Protocol) eingerichtet sind. 

5 15. Diagnoserechnerknoten nach einem der vorangehenden AnsprQche, 
gekennzeichnet durch ein programmtechnisch Oder softwaremaiiig derart 
eingerichtetes Kommunikationsmodul, dass dadurch einer oder mehrere der 
Prozessrechnerknoten (4) an das Ethernet Oder sonstige Bus- 
Kommunikationssystem angebunden werden kann. 

10 

16. Diagnoserechnerknoten nach einem der vorangehenden Anspruche, 
gekennzeichnet durch ein Aniagen-Managementmodul mit Informationsdaten 
uber die Konfiguration der technisch-physikalischen Prozesse nebst zugehOrigen 
Prozessrechnerknoten (4) und einer oder mehrerer Funktionskomponenten, die 

15 zur Visualisierung der Konfiguration in Verbindung mit den Client-Rechnerknoten 

und/oder zum Bereithalten der Informationsdaten fur weitere 
Datenverarbeitungsprozesse ausgebildet sfnd. 

17. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul als Software- 
20 und/oder Firmwaremodul, jeweils for das Netzwerk nach einem der Anspruche 1 

bis 11, gekennzeichnet durch eine erste, dem wenlgstens einen 
Diagnoserechnerknoten zugeordnete Schnittstelle, welche zur Kommunikation 
Qber Protokolle der TCP/IP-Familie. einschlieBlich UDP/IP, vorzugsweise auf der 
Basis des Ethernet programmiert 1st, und durch eine oder mehrere zweite, einem 

25 Oder mehreren der Prozessrechnerknoten (4) zugeordnete Schnittstellen, wobei 

die erste und die eine oder mehreren zwelten Schnittstellen miteinander 
koppelbar sind Qber einen oder mehrere Informationsbroker, die jeweils 
programm- und/oder schaltungstechnisch als Submodule zur bidirektionalen, 
anfrage- und/oder ereignisbasierten Datenkommunikation zwischen erster und 

30 zweiter(n) Schnittstelle(n) ausgebildet sind. 
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18. Kommunikationsrechnerknoten (5) Oder Kommunikationsmodul nach Anspruch 
17, dadurch gekennzeichnet, dass die erste Schnittstelle zur Kommunikation auf 
der Basis von XML-Protokollen ausgebildet ist. 

19. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach Anspruch 
17 Oder 18, dadurch gekennzeichnet, dass die zweite Schnittstelle zur 
Verbindung mit einem seriellen Kommunikationssystem ausgebildet ist. 

20. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden Anspruche, dadurch gekennzeichnet, dass der eine oder die 
mehreren Informationsbroker eine oder mehrere Funktionskomponenten 
umfassen, die zur Fehlersuche oder Diagnose im Bereich der 
ProzeBrechnerknoten und/oder technisch-physlkalischen Prozesse ausgebildet 
sind. 

21. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden Anspruche, dadurch gekennzeichnet, dass mehrere 
Informationsbroker mit zueinander unterschiedlichen Funktionalitaten 
eingerichtet und mit einem Connection-Manager verbunden sind, der programm- 
und/oder schaltungstechnisch als Submodul zur Realisierung vorspezifizierter 
Prioritatsstufen ausgebildet ist, gemaB welcher mit der oder den zweiten 
Schnittstellen jeweils ein bestimmter der mehreren Informationsbroker 
verbindbar ist, die jeweils eine Kommunikationsanforderung an den oder die 
Prozessrechnerknoten (4) aufweisen. 

22. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden Anspruche. gekennzeichnet durch einen Software- 
Informationsbroker zur bidirektionalen Obertragung von Firmware oder sonstigen 
Daten oder kompletten Datensatzen von der ersten zu der oder den zweiten 
Schnittstellen. 
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23. Kommunikationsrechnerknoten (5) Oder Kommunikationsmodul nach Anspruch 
22, dadurch gekennzeichnet, dass zwischen dem Software-lnformationsbroker 
und der ersten Schnittstelle ein FTP (File Transfer Protocol) - Server 
zwischengeschaltet ist. 

5 

24. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch die Austattung mit einem 
nichtfluchtigen Schreib-ZLesespeicher, insbesondere Flash-Speicher, mit 
welchem einer oder mehrere der Informationsbroker in Verbindung steht. 

10 

25. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch einen Parameter- 
Informationsbroker zur Realisierung "einer vorzugsweise XML-basierten 
Schnittstelle fur Lesen und/oder Schreiben von Parametern in einem oder 

15 mehreren zugeordneten Prozessrechnerknoten (4). 

26. Kommunikationsrechnerknoten (5) Oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche. gekennzeichnet durch einen Fehler/Ereignis- 
Informationsbroker, der zur Kommunikation mit einem XML-basierten Protokoll 

20 auf der Basis von TCP/IP Qber die erste Schnittstelle ausgebildet und mit einem 

von extern derart konfigurierbaren PrOf- und Triggerwerk versehen ist, dass bei 
Eintritt eines vorspezifizierten Ereignisses, beispielsweise Gberschreitens eines 
Toleranzlimits, im Bereich des oder der Prozessrechnerknoten (4) und/oder 
technisch-physikalischen Prozesses selbsttatig eine korrespondierende 

25 NachrichtenQbermittlung zur ersten Schnittstelle ausgelOst wird. 

27. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach einem der 
vorangehenden AnsprQche, gekennzeichnet durch die Einrichtung eines 
Interpreters fUr die Ablauffahigkeit von Skripten, die zum Zugriff auf 

30 Funktionselemente und/oder Informationsdaten in dem oder den 

Informationsbrokern zwecks Ausfuhrung von Oberwachungs- und 
Diagnosefunktionen ausgebildet sind. 
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28. Kommunikationsrechnerknoten (5) oder Kommunikationsmodul nach Anspruch 
27, dadurch gekennzeichnet. dass der Interpreter mit einem mit der ersten 
Schnittstelle verbundenen FTP (File Transfer Protocol) - Server derart kcppelbar 
ist dass Ober die erste Schnittstelle empfangene Skripte ausfuhrbar sind. 

29. Kommunikationsrechnerknoten (5) nach einem der vorangehenden Anspruche, 
gekennzeichnet durch eine Ausbildung als Zusatzbaukomponente fur einen 
jeweiligen Prozessrechnerknoten (4) und/oder eine bauliche Integration mit 
einem ProzeSrechnerknoten. 

30. Kommunikationsmodul nach einem der vorangehenden AnsprOche, 
gekennzeichnet durch eine zumindest teilwelse ablauffahige Implementierung 
auf der Hardware eines Prozess- und/oder Diagnoserechnerknotens. 
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